The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, the approaches described in this section may not be prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Traditionally, different disciplines of software development are managed separately by different groups of users. The different groups of users involved in software development use different applications and tools to perform different tasks. For example, business managers traditionally use a Requirement Management (RM) tool to articulate and list all the requirements for a software product. When the requirements are finalized, the business managers typically provide the requirements to software engineers in the form of reports, e-mails, and/or other types of requirement documentation. Based on the provided requirements, the software engineers typically use a Configuration Management (CM) tool to design, set up, and version-control one or more software projects and deliverables that implement these requirements in the software product.
The above traditional approach of software development is based on compartmentalizing the tasks performed by the different groups of users involved in the software development. Each group of users typically uses applications and tools that facilitate efficient performance of only those tasks and functions of the software development process that are assigned to that group. For example, business managers traditionally do not need information from a CM tool because the business managers would not perform any functions or tasks for designing and implementing the software product. Similarly, software engineers traditionally do not need information from a RM tool because software engineers would typically not perform any functions or tasks for determining and articulating the requirements for the software product.
One disadvantage of the traditional approach of software development is that there is no efficient way of managing those functions or tasks that involve multiple software development disciplines. For example, the traditional approach does not provide an efficient mechanism of determining how a particular requirement is actually implemented in the software product. In order to determine which software components, modules, libraries, and/or files implement a particular feature of a software product, a business manager would need to review the requirement documentation in which the particular requirement was communicated to the software engineers. The business manager would then need to review information stored in a CM tool to determine which software components or files implement the particular requirement in the software product. Similarly, in order to determine by whom or why a particular requirement was specified for the software product, a software engineer would need to review the requirement documentation in which the particular requirement was communicated from the business managers, and then review the information stored in a RM tool to determine why the particular requirement was specified for the software product.
Another disadvantage of the traditional approach of software development is that after a product is completed and released to the customers, there is no efficient mechanism of evaluating how a particular change to the requirements implemented in the software product would affect an effort to re-develop the software product to include the particular change.
The disadvantages of the traditional approach of software development described above are not unique only to the requirement management and configuration management disciplines of software development. Rather, similar disadvantages may be encountered in other software development disciplines such as, for example, marketing management, customer service management, testing management, and product release management.